Add re-export of rethrowSTM - #100

Hi Wolfgang. Thanks for opening this MR. Do you intend for this to get merged before upstream, i.e. is it necessary this lands before the GHC MR lands?

Well, this re-export only works with rethrowSTM having been added to ghc-internal; so GHC !16501 should be adopted before this change to stm is adopted.

By the way, there is CLC proposal #436, which deals with the addition of rethrowSTM.

should be adopted before this change to stm is adopted.

I was asking because obviously CI with upstream GHC is currently failing but if you had needed to bump the submodule upstream with the new version of STM then that obviously creates a cycle. Since the CI against upstream is new I think I would have had to come up with a solution here but if you say this can be merged after upstream, then all is good.

After your MR against GHC has landed, we'll wait until it appears in nightly, then build this branch against the bindist that has this and then merge.

I assume you have an okay from upstream for this to be backported to 10.0?

should be adopted before this change to stm is adopted.

I was asking because obviously CI with upstream GHC is currently failing but if you had needed to bump the submodule upstream with the new version of STM then that obviously creates a cycle. Since the CI against upstream is new I think I would have had to come up with a solution here but if you say this can be merged after upstream, then all is good.

Yes, also with !16501, nothing in GHC, ghc-internal, or base needs this change to stm, as !16501 simply provides rethrowSTM. So there is no cycle here.

I assume you have an okay from upstream for this to be backported to 10.0?

Aargh, I forgot that 10.0 is already in the freezer. I guess I should get such a backport permission then. Where and how do I have to apply for it?

Where and how do I have to apply for it?

Zubin is the release manager, I pinged him on your upstream MR.

As we just discussed in more hidden channels, the corresponding GHC contribution will not be backported for GHC 10.0. 🙂

When I generate stm documentation from within the GHC source tree, all the re-exported entities in Control.Monad.STM lack their documentation. I’ve tried generating stm documentation with Cabal, but this complains about test-framework-hunit missing, although this package is available and although I only want to build documentation, not test. Could you please advise how I could check whether documentation generation via Cabal works and preferable also why GHC’s documentation generation does not work and what to do about this?